Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark some methods as internal #3793

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

JasonGrace2282
Copy link
Member

@JasonGrace2282 JasonGrace2282 commented May 30, 2024

This is an idea of an implementation for #3792

It defines a decorator that modifies the function's docstring to warn end-users that it is marked as an implementation detail.

Example

TODO

  • Figure out why sometimes the decorator does not produce the warning directive

@JasonGrace2282 JasonGrace2282 marked this pull request as ready for review May 31, 2024 01:57
manim/utils/decorators.py Outdated Show resolved Hide resolved
@JasonGrace2282 JasonGrace2282 added this to the v0.19.0 milestone Jun 10, 2024
Copy link
Member

@behackl behackl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine! Left one suggestion and a bunch of comments where I thought it is somewhat debatable that a method would be marked as internal.

I like the mechanism though, am happy to merge this in principle. Thanks for your work!

@@ -1712,6 +1714,7 @@ def stretch_to_fit_depth(self, depth: float, **kwargs) -> Self:

return self.rescale_to_fit(depth, 2, stretch=True, **kwargs)

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, I don't remember. However, I think that it's more common to use move_to or set_(x|y|z) as opposed to this method.
This PR was mostly an introduction of concept, so I'm happy to remove it if you disagree.

@@ -1902,6 +1905,7 @@ def set_colors_by_radial_gradient(
)
return self

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was already a set_colors_by_gradient that used this internally and returning Self, so I figured that should be the public one.

@@ -1915,6 +1919,7 @@ def set_submobject_colors_by_gradient(self, *colors: Iterable[ParsableManimColor
mob.set_color(color, family=False)
return self

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, there was already a set_colors_by_radial_gradient that used this internally and returning Self, so I figured that should be the public one.

@@ -2044,6 +2049,7 @@ def get_points_defining_boundary(self) -> Point3D_Array:
def get_num_points(self) -> int:
return len(self.points)

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe also borderline

manim/mobject/mobject.py Outdated Show resolved Hide resolved
@@ -2784,6 +2795,7 @@ def add_n_more_submobjects(self, n: int) -> Self | None:
def repeat_submobject(self, submob: Mobject) -> Self:
return submob.copy()

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

borderline?

@@ -708,6 +712,7 @@ def set_shade_in_3d(
submob.z_index_group = self
return self

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

boderline?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mostly added this because of discussions on whether to make points a property (to add some memoization stuff).

@@ -1800,6 +1834,7 @@ def get_point_mobject(self, center: Point3D | None = None) -> VectorizedPoint:
point.match_style(self)
return point

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

borderline?

@@ -1824,6 +1859,7 @@ def interpolate_color(
val = val.copy()
setattr(self, attr, val)

@internal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

borderline?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it hard to think of a case where a user would need this, and (I can't remember) but there's a chance this changes in experimental.

manim/utils/decorators.py Outdated Show resolved Hide resolved
@JasonGrace2282
Copy link
Member Author

JasonGrace2282 commented Jul 14, 2024

Before this PR is merged, it might also be worth checking if there is a performance penalty.
Currently, this implementation does not take docstrings from parent classes (which is what inspect.getdoc does), as doing so is obviously slower - maybe there's a way we can only modify the docstrings while sphinx is building the docs?
EDIT: Environment variables might be the best way to go here - according to the os docs environment variables are stored in memory so it should just be a lookup away?

EDIT 2: Just did some benchmarking, the performance penalty from inspect.cleandoc is very low. Considering that it is only applied once at import time, it should be negligible.

@JasonGrace2282
Copy link
Member Author

JasonGrace2282 commented Jul 14, 2024

it is somewhat debatable that a method would be marked as internal.

My view is always that when in doubt, mark it as internal. This gives us the most flexibility for the future (even though we're not at 1.0.0 yet!), and changing something from internal → public is not a major semvar change.

@JasonGrace2282 JasonGrace2282 added enhancement Additions and improvements in general needs discussion Things which needs to be discussed before implemented. labels Jul 25, 2024
@JasonGrace2282 JasonGrace2282 modified the milestones: v0.19.0, v0.20.0 Jul 25, 2024
@JasonGrace2282 JasonGrace2282 removed the needs discussion Things which needs to be discussed before implemented. label Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Additions and improvements in general
Projects
Status: 🆕 New
Development

Successfully merging this pull request may close these issues.

3 participants